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ABSTRACT 

The overall goal of the 2 nd Generation RLV Program is to substantially reduce 
technical and business risks associated with developing a new class of reusable 
launch vehicles. NASA’s specific goals are to improve the safety of a 2 nd - 
generation system by 2 orders of magnitude — equivalent to a crew risk of 1 -in- 
10,000 missions — and decrease the cost tenfold, to approximately $1 ,000 per 
pound of payload launched. 

Architecture definition is being conducted in parallel with the maturating of key 
technologies specifically identified to improve safety and reliability, while reducing 
operational costs. An architecture broadly includes an Earth-to-orbit reusable 
launch vehicle, on-orbit transfer vehicles and upper stages, mission planning, 
ground and flight operations, and support infrastructure, both on the ground and 
in orbit. The systems engineering approach ensures that the technologies 
developed — such as lightweight structures, long-life rocket engines, reliable 
crew escape, and robust thermal protection systems — will synergistically 
integrate into the optimum vehicle. 

Given a candidate architecture that possesses credible physics/processes and 
realistic technology assumptions, the next set of analyses address the system’s 
functionality across the spread of operational scenarios characterized by the 
design reference missions. The safety/reliability and cost/economics associated 
with operating the system will also be modeled and analyzed to answer the 
questions “How safe is it?” and “How much will it cost to acquire and operate?” 

The systems engineering review process factors in comprehensive budget 
estimates, detailed project schedules, and business and performance plans, 
against the goals of safety, reliability, and cost, in addition to overall technical 
feasibility. This approach forms the basis for investment decisions in the 2 nd 
Generation RLV Program’s risk-reduction activities. Through this process, NASA 
will continually refine its specialized needs and identify where Defense and 
commercial requirements overlap those of civil missions. 


1.0 Background 


The U.S. Space Launch Initiative (SLI) is the central focus of the National 
Aeronautics and Space Administration’s (NASA) Integrated Space Transportation 
Plan (ISTP), a comprehensive strategy for revolutionizing space transportation in 
the 21 st century. The ISTP includes: (1) Space Shuttle Safety Upgrades. (21 near- 
term investments in 2 na Generation Reusable Launch Vehicles (RLV), and (3) 
long-term research for 3 rd Generation RLVs and In-Space Transportation 
systems for future space exploration. 

Building on 20 years of success with America’s 1st Generation RLV — the Space 
Shuttle — the SLI defines the plan of action to design space transportation 
systems and develop advanced technologies for America’s next-generation RLV. 
It addresses business risk reduction for 2 nd Generation RLV development and 
technology risk reduction for NASA-unique systems (i.e., crew survival features), 
as well as enables potential Alternate Access to the International Space Station 
(ISS). Therefore, SLI is synonymous with the 2 nd Generation RLV Program, 
which is managed by NASA’s Marshall Space Flight Center (MSFC), with 
participation from NASA field Centers and aerospace contractors from coast to 
coast. 

The 2 nd Generation RLV Program’s scope is not limited solely to the launch 
vehicle, but encompasses all elements of a space transportation system 
architecture, an integrated set of elements consisting of: 

1 . Earth-to-orbit launch vehicle 

2. On-orbit transfer vehicles and upper stages 

3. Mission planning 

4. Ground and flight operations 

5. Ground-based and on-orbit support infrastructure. 

Figure 1 illustrates the interrelated nature of these elements, which function 
synergistically to accomplish the space transportation mission. 

Jhe 2 nd Generation RLV , Program is based on the philosophy that frequently 
launching NASA payloads on highly reliable reusable launch vehicles will 
significantly reduce the. cost of space access, allowing the Agency to focus 
resources on its core missions of scientific discovery and exploration. [1] Overall 
goals are to substantially reduce technical and business risks associated with 
developing safe and reliable RLVs. NASA’s specific goals are to: 

• Improve safety — risk of crew loss — to less than 1 -in-1 0,000 missions 

• Decrease cost by a factor of 10 — to approximately $1 ,000 per pound of 
payload launched to low-Earth orbit (LEO). 



Legend: 

CTV — Crew Transfer Vehicle 
OTV — Orbital Transfer Vehicle 
OCTV — Orbital Crew Transfer Vehicle 
ISSMM — International Space Station 
Multipurpose Module • 
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Figure 1 . Space Transportation System elements. 


Therefore, NASA is investing in strategic technology development in these areas 
for the express purpose of increasing safety and decreasing cost. While the 
space transportation architecture drives specific technology developmental 
objectives, the technologies ultimately enable the space transportation 
architecture. 

















The systems engineering and integration task consists of two distinct activities to 
be accomplished during the formulation phase covered by the 2 nd Generation 
RLV Program: 

1 . Conduct System Studies — Define and comparatively evaluate candidate 
space tra nsportation architectures, and develop and validate the 
associated systems requirements. 

2. Coordinate Technology Developments — Maintain a technology portfolio 
to support evolving space transportation architecture(s). 

Following is a description of the top-level systems engineering and integration 
processes developed to define a viable RLV architecture and mature the key 
technologies that will enable that architecture to meet Program objectives. 


2.0 Systems Engineering Process Overview 

The overall systems engineering and integration process is illustrated in Figure 5. 
System definition begins with communication with customers and stakeholders. 
The Program solicits customer and stakeholder needs and wants, and provides 
space transportation system capabilities and costs as feedback. The systems 
definition activity quantifies customer needs and wants in terms of Level 1 
Program Requirements and design reference missions (DRM), and quantifies 
system capabilities and costs in terms of mission-level figures of merit (FOM) — 
measures to which customers and stakeholders can relate. This activity also 
articulates the space transportation system’s intended usage scenario in a 
Operations Concept Document for the architecture. 


) 



Figure 2. Systems engineering and integration process. 


The systems requirements activity takes the system definition and develops a 
requirements allocation and flow-down for the space transportation system. This 
is the key integrating mechanism for the Program. It includes requirements 
synthesis with the individual projects within the advanced technology portfolio. 

Given a requirements basis for a space transportation system, the systems 
analysis activity validates the requirements, using a design analysis cycle (DAC) 
process. The feedback provided indicates which requirements are valid and 
which are not; this information, in turn, influences the technology portfolio or may 
even affect Level 1 Requirements. The output of a design analysis cycle will also 
include the mission-level figures of merit in support of the system definition 
activity. Over time, successive cycles will result" in convergence to the optimal 
space transportation system architecture, as illustrated in Figure 6. 
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Figure 3. Convergence to the optimal Space Transportation System 
architecture. 




Reliability, maintainability, ^and supportability engineering are closely interrelated 
design support disciplines that provide essential systems analysis capability for 
reusable systems requiring high reliability, high availability, and low operational 
cost. Each RMS engineering discipline has been practiced in industry and within 
the Department of Defense for decades following standard methodologies. In the 
2 nd Generation RLV Program these disciplines will be brought together similar to 
the way they have been practiced in industry and in other government agencies 
through an integrated RMS Process. 


3.1 Overall Systems Analysis Process 







Rigorous system analysis will indicate whether a system configuration, such as a 
candidate 2 nd Generation RLV architecture, will satisfy requirements. The 
systems analysis process addresses five criteria, as shown in Figure 13: 

1. Technical Viability 

2. Technology Risk 

3. Design Reference Missions 

4. Safety/Reliability 

5. Cost/Economics. 
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Figure 4. Criteria addressed by the systems analysis process. 


Obviously, the first step in an architecture systems analysis is to model the 
system and determine whether it is credible from a physical science viewpoint. 
















This series of analyses will answer rudimentary questions such as “Can it reach 
orbit?” and “Will it survive the natural environment?” 

Given that the configuration possesses credible physics and processes, systems 
analyses then focus on the technology readiness levels (TRL) of the various 
architecture elements. This series of analyses answers questions such as “Will 
the technology be ready in time?” and ‘What is the impact if the technology does 
not achieve performance goals?” The risk reduction technology projects and the 
mission requirements synthesis process provide data to reduce uncertainty in 
these analyses. 

Given a candidate architecture that possesses credible physics/processes and 
realistic technology assumptions, the next set of analyses address the system’s 
functionality across the spread of operational scenarios characterized by the 
design reference missions. The safety/reliability and cost/economics associated 
with operating the system will also be modeled and analyzed to answer the 
questions “How safe is it?” and “How much will it cost to acquire and operate?” 
The parameters included in the systems analysis process are depicted in Figure 
13. Note also that the mission-level FOMs discussed in Section 2.1 are a subset 
of the systems analysis parameter set. 

Repeating the systems analysis process for a large number of candidate 
architectures will validate the systems requirements. For example, if multiple 
architectures meet the 1 -in-1 0,000 loss of crew requirement, it may be assumed 
this is a valid requirement that can be met by the 2 nd Generation RLV when it is 
developed and operational. Conversely, if a requirement cannot be validated in 
that no candidate system architectures meet the requirement, the systems 
analysis process provides for requirements “push-back” to establish a valid 
requirement. Because the requirements are allocated across multiple 
architectural elements and based on assumed performanpe of various 
technologies^ requirements “push-back* will lead to a requirement reallocation or 
relaxation for the architectural elements and/or the technologies, which prompts 
a new analysis. 

One iteration of the systems analysis process is called a design, analysis cycle. 
Over time, the character of DACs will evolve, growing in fidelity and precision; as 
it becomes available, test data resulting from risk reduction technology projects 
will be included in the DACs. In the near term, DACs will focus on the evaluation 
of a large number of candidate system architectures. Subsequently, the DACs’ 
focus will shift toward greater detail on a smaller number of candidate 
architectures. Accordingly, the systems requirements validation will approach 
completion and the validation focus will shift to lower-tier requirements 
associated with architectural elements, subsystems, and components. Likewise, 
the mission-level FOMs will begin to stabilize and generally exhibit reduced 
variability over time. In this way, the systems analysis process: (1) validates 


systems requirements, and (2) determines the relative merit of various candidate 
systems architectures and technologies. 


The Integrated RMS Process 



Figure 2 


3.2 Reliability, Maintainability/ and Supportability (RMS) Process 


The RMS Process, illustrated in Figure 2, integrates the disciplines of reliability, 
maintainability, and supportability engineering through a specific sequencing of 
related RMS modeling and analysis tasks and through the flow of specific RMS 
data between the sequenced RMS tasks - The RMS Process also integrates the 
RMS modeling and analysis tasks, through the systems engineering process, 
with design engineering and with other engineering support disciplines such as 
cost and assurance. : 












The basic RMS Process begins with identification of failure states/events 
associated with the design, their severity, their causes, and their effects. This is 
done primarily through a Failure Modes and Effects Analysis (FMEA) of the 
design and is supported by Hazard Analyses and Human Factors Analyses. 
Next, reliability modeling and analysis develops reliability models of the failure 
modes/events and then arranges the individual models into a failure 
structure/logic model representing the ways in which system function may be 
lost. This logic model is executed analytically or through simulation to produce 
the primary output of the reliability modeling and analysis task: an estimation of 
system capability to meet reliability and safety figures of merit of PLOC, PLOV, 
PLOM, and PLOP. At the same time, parameters from reliability models along 
with certain FMEA data serve as input into reliability-centered maintenance 
(RCM) analysis. The RCM analysis takes this input and runs it through an 
established RCM logic flow to generate an inventory of maintenance significant 
items (MSI) and basic maintenance actions required to retain or restore MSI 
function at or to specified levels of reliability/safety. The inventory of MSI and 
basic maintenance actions serves as primary input into both the maintainability 
and supportability modeling and analyses tasks that are closely interrelated and 
performed concurrently. 

Maintainability modeling and analysis begins with the development of a top-level 
maintenance event sequence model initiated during conceptual design. It is 
continually decomposed to lower levels of indenture with increasing definition of 
system architecture, of maintenance and support tasks, and of maintenance 
packaging schemes. Once complete it provides a definitive maintenance and 
support (e.g., ground processing) flow model. Maintainability models estimating 
elapsed time for individual and grouped maintenance actions/events are 
developed concurrently at each level of indenture in the maintenance event 
sequence model. A downtime analysis is performed when required by executing 
the maintenance event sequence model analytically or through simulation. The 
-downtime analysis estimates the capability of thei maintenance and support 
system to deliver a space flight system ready for integration or flight within 
specified time constraints. This output at the vehicle level is combined with 
estimates of the start-up reliability of the launch vehicle and with estimates of the 
probability, of the launch vehicle architecture not exceeding day-of-launch 
Environmental constraints to produce an estimate of the launch availability FOM 
for the launch vehicle architecture. 

Supportability modeling and analysis begins primarily with the maintenance task 
analysis that is initiated for each maintenance action output of the RCM analysis. 
This analysis is a decomposition of each maintenance action into all necessary 
steps for successful completion. A supportability analysis is performed 
concurrently with and on the maintenance task analysis to determine the required 
resource loading (facilities, personnel, support equipment, parts, etc.) for each 
maintenance action. Following the maintenance task analysis and concurrent 
supportability analysis, the individual maintenance actions are grouped into 


packaged sets of tasks that most effectively and efficiently meet mission, 
reliability, and cost requirements. The final set of packaged maintenance actions 
are documented (e.g., Space Shuttle OMRSD) for use by maintenance 
engineering. The supportability analysis is updated to reflect the packaged tasks 
and the output is provided to cost analysis in the form of total support resources 
per cost-breakdown-structure to support estimates of recurring cost. 


3.3 Tools, MODELS and Databases 

The RMS process will require both existing and new tools, models, and 
databases. Existing tools may be used for certain RMS modeling and analysis 
tasks. However, new software tools will be needed for certain analyses (e.g., 
RCM analysis) and to integrate the set of RMS models and analyses. Existing 
models such as the Space Shuttle Quantitative Risk Assessment System 
(QRAS) may be used extensively for reliability modeling, but new system-level 
models will be required for some reliability analysis, downtime analysis, and 
supportability modeling and analysis. These needs will be identified and met 
primarily through the Advanced Engineering Environment (AEE) activities, which 
utilizes a data dictionary for the input and output variables required by the models 
and tools in the AEE. The 2GRLV-SEAEE-PLAN-001, Advanced Engineering 
Environment (AEE) Project Plan provides further detail on the AEE processes 
and activities. Among existing databases that may prove useful are the Problem 
Reporting and Corrective Action (PRACA) database and A new database, the 
Baseline Comparison System (BCS), is being developed that will attempt to 
collect applicable data from a number of existing Space Shuttle databases, 
including the PRACA database, and merge the data into one RMS database. 


3.4 Products 

- i 


The RMS process will provide a set of integrated RMS products over the life of 
the 2GRLV program. Table X, RMS Program Products and Schedule, shows 
these products relative to major program ibilestones. The primary purpose of 
these products is to provide objective analytical evidence at each program review 
that candidate space transportation architectures meet the Level 1 RMS-related 
Requirements. 
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